<html>
<head><meta charset="utf-8"><title>acting on compilation errors · general · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/index.html">general</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/acting.20on.20compilation.20errors.html">acting on compilation errors</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="211371442"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/acting%20on%20compilation%20errors/near/211371442" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Karel Kubat <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/acting.20on.20compilation.20errors.html#211371442">(Sep 26 2020 at 17:51)</a>:</h4>
<p>Are there currently any RFCs for custom compilation error handling? I recently read a blog (which link I lost :( ) talking about the concept of library authors being able to generate custom compilation errors based on existing compilation errors. The idea would be to use a decorator on items, which if the item is used by a library consumer and the code results in a compilation error, the error can be inspected by the library authors code and possibly a better error may be returned.</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="cp">#![compile_err(my_handler)]</span><span class="w"></span>
<span class="k">pub</span><span class="w"> </span><span class="k">fn</span> <span class="nf">somethingVeryComplicated</span><span class="o">&lt;</span><span class="n">o</span>: <span class="nc">OverSomeVeryStrangeGeneric</span><span class="o">&gt;</span><span class="p">()</span><span class="w"> </span>-&gt; <span class="nc">WowComplicated</span><span class="w"> </span><span class="p">{</span><span class="o">..</span><span class="p">.}</span><span class="w"></span>

<span class="cp">#![compile_err_handler]</span><span class="w"></span>
<span class="k">pub</span><span class="w"> </span><span class="k">fn</span> <span class="nf">my_handler</span><span class="p">(</span><span class="n">e</span>: <span class="nc">rust_compiler</span>::<span class="n">Error</span><span class="p">)</span><span class="w"> </span>-&gt; <span class="nc">rust_compiler</span>::<span class="n">Error</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">       </span><span class="c1">// check the error; if it is some common user programming error, emit a new error with a more useful help message</span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>

<p>Would this idea be crazy, aside from the non trivial implementation?</p>



<a name="211379295"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/acting%20on%20compilation%20errors/near/211379295" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/acting.20on.20compilation.20errors.html#211379295">(Sep 26 2020 at 19:38)</a>:</h4>
<p>The problem is if not very well designed this might make it impossible to improve compiler errors later one.</p>
<p>Furthermore errors appear on a later stage so exposing context information without exposing compiler internals is tricky.</p>
<p>Furthermore which rustc error appears on a certain kind of "programming error" isn't always clear or stable. Like type inference might still work with the "wrong" code inferring the a wrong type <br>
and create a error at a different place.</p>
<p>Still a very interesting idea, just a bit tricky to stabilize this.</p>
<p>Oh and as far as I remember for some errors user can provide a (static) hint which is then included in the error message, like for <code>#[must_use]</code> as far as I remember.</p>



<a name="211379399"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/acting%20on%20compilation%20errors/near/211379399" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/acting.20on.20compilation.20errors.html#211379399">(Sep 26 2020 at 19:40)</a>:</h4>
<p>From the reference:</p>
<blockquote>
<p>The <code>must_use</code> attribute may include a message by using the <em>MetaNameValueStr</em> syntax such as <code>#[must_use = "example message"]</code>. The message will be given alongside the warning.</p>
</blockquote>



<a name="211379485"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/acting%20on%20compilation%20errors/near/211379485" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/acting.20on.20compilation.20errors.html#211379485">(Sep 26 2020 at 19:43)</a>:</h4>
<p>So my guess is: Possible (in some limits), Implementable but hard to get right and hard to stabilize.</p>



<a name="211384497"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/acting%20on%20compilation%20errors/near/211384497" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Karel Kubat <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/acting.20on.20compilation.20errors.html#211384497">(Sep 26 2020 at 22:01)</a>:</h4>
<p>Yeah, I haven't even started thinking about API stabilization etc, just throwing the idea in here. I'm mainly looking at such a feature because I am generating Rust code, and I am not able catch all errors on the front end (due to type inference etc). In my case, if a certain section of rust would not compile, I'd be able to retrace it to the original template, and point out the error.</p>
<p>I might write a proposal, just to get such a feature documented. If properly supported, I think it would be a killer feature,  but also one that might unnecessarily pin down compiler errors to semver.</p>



<a name="211385795"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/acting%20on%20compilation%20errors/near/211385795" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/acting.20on.20compilation.20errors.html#211385795">(Sep 26 2020 at 22:39)</a>:</h4>
<p>One random idea I just had for the case of  additional compiler error information in generated code (but not necessary for code using that generated code):</p>
<ol>
<li>
<p>have some way to "mark" a thing which might have an error (e.g. using attributes as we can attach them syntax wise to a lot of things)  E.g. <code>#[additional_error_info(my_error_thingy)]</code> or so.</p>
</li>
<li>
<p>Pass in a <em>non-exhoustive</em> enum of error kinds where each variant has a single opaque type instance which might provide methods with some metadata </p>
</li>
<li>
<p>Allow the registered error function to emmit some additional error hint. I.e. you get the normal error message and any number of additional hint e.g. <code>"hint: For the foobar code gen to work the type </code>MyType<code> need to implement </code>FooBar<code> with </code>FooBar::Yo<code> implementing </code>BarFoot<code>."</code></p>
</li>
</ol>
<p>I thing something in this direction could have the best chance to work, but also would be the least useful as it probably can't do things like marking the wrong code or similar.</p>
<p>Through another potential problem I found is compiler performance. Not because of the plugin being slow but because of how the compiler internal code might become constrained so that it can work. <em>But I don't know much about the compiler internals so thats just spekualtion that this might be another problem</em>.</p>



<a name="211388807"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/acting%20on%20compilation%20errors/near/211388807" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Karel Kubat <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/acting.20on.20compilation.20errors.html#211388807">(Sep 27 2020 at 00:07)</a>:</h4>
<p>A big difference comparing this feature to proc-macros, is that the error does not necessarily need to be handled: compilation has failed anyway, we are just concerned with smarter formatting and better tips and hints. Old handler code which relies on perhaps an older rustc error type does not need to be able to parse the error, and may instead be omitted/return the original error.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>